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Abstract 

Side channels remain a challenge to information flow 
control and security in modern computing platforms. Re¬ 
source partitioning techniques that minimise the number 
of shared resources among processes are often used to 
address this challenge. In this work, we focus on multi¬ 
core platforms and we demonstrate that even seemingly 
strong isolation techniques based on dedicated cores and 
memory can be circumvented through the use of thermal 
side channels. Specifically, we show that the processor 
core temperature can be used both as a side channel as 
well as a covert communication channel even when the 
system implements strong spatial and temporal partition¬ 
ing. Our experiments on an x86-based platform demon¬ 
strate covert thermal channels that achieve up to 12.5 bps 
and a weak side channel that can detect processes exe¬ 
cuted on neighbouring cores. This work therefore shows 
a limitation in the isolation that can be achieved on exist¬ 
ing multi-core systems. 


1 Introduction 

Side channels have for a long time remained an open 
threat to information flow control and isolation tech¬ 
niques in a variety of contexts including cloud and mo¬ 
bile computing [ |39[|59jj60||64) . Such channels can be 
used for data exfiltration from a victim [64] and be ex¬ 
ploited by colluding applications to covertly exchange 
information [ |50||59] , 

A common technique to mitigate side channel at¬ 
tacks that leverage co-location is to dedicate resources 
(e.g., processor cores, memory) to individual processes 
for the duration of their execution. Although seemingly 
inefficient, such a technique is becoming viable with 
the appearance of multi and many-core systems which 
contain hundreds of cores mmm- However, it has 
already been shown that, due to their architecture and 
use, multi-core systems do not trivially protect against 


all types of information leakage — side channels have 
been demonstrated leveraging shared caches f57) , mem¬ 
ory bus |59) , network stacks 1 43) , virtual memory 154), 
I/O devices [52 J etc. These side-channels, however, still 
exploit the resources that particular multi-core platforms, 
for performance and other reasons, share among the pro¬ 
cesses. This resulted in proposals that solve this problem 
by partitioning the shared resources when possible, for 
example, dividing caches ]57| and bus bandwidth |26|. 


In this paper, we show that even strong isolation tech¬ 
niques based on dedicated cores and memory can be cir¬ 
cumvented in multi-core systems through the use of a 
thermal side-channel. For this we leverage the thermal 
properties of multi-core systems and access to core tem¬ 
perature information that, for performance reasons, is 
available to processes on these platforms. First, the ther¬ 
mal capacitance and resistance of computing platforms 
result in remnant heat from computations, i.e., the heat is 
observable even after that computation has stopped. As a 
result, information about one process may leak to another 
that follows it in the execution schedule. Second, the 
effects of heat resulting from processes running on one 
core can be observed on other cores across the chip. This 
leaks information about a process to its peers running 
on other cores in a processor chip. We demonstrate our 
attacks on commodity multi-core systems. So far, ther¬ 
mal (heat) side channels have not been studied on these 
systems. There is a trend towards exposing such data to 
users and allowing them to make thermal management 
decisions based on it ED- For example, temperature in¬ 
formation is accessible from user-space on modern Linux 
systems |Tj|. This paper highlights the tension between 
building thermally-efficient systems which requires ex¬ 
posing high-quality temperature data to applications and 
securing them. 


In summary, we make the following contributions: 
(i) We demonstrate the feasibility of using thermal side 
channels for communication between colluding applica¬ 
tions and measure the throughput of such a channel on an 



Intel-based platform. The challenges in building such a 
channel include the system’s thermal capacitance, effect 
of cooling on multi-core systems and resolution limita¬ 
tions of the thermal sensors available on these platforms, 
(ii) We explore the factors that influence the throughput 
of this side channel: frequency and relative locations of 
the colluding applications (processes), (iii) We demon¬ 
strate the existence of limited thermal side channel leak¬ 
age from processes running on adjacent cores that al¬ 
low identification of applications based on their thermal 
traces. On existing systems, heat-based leakage is non¬ 
trivial to avoid without a performance penalty; we dis¬ 
cuss possible countermeasures to eliminate or limit the 
impact of such attacks. 

The rest of this paper is organised as follows. In Sec¬ 
tion]^ we discuss the background and motivation for our 
work. Section |3] discusses the thermal behaviour of x86 
platforms and Section [4] describes how these properties 
can be exploited to create thermal channels. In Sec¬ 
tion |3 we demonstrate the feasibility of using thermal 
side channels for covert communication even in systems 
with isolation based on spatial and temporal partition¬ 
ing. Section [6] demonstrates that limited side channel 
leakage can occur through thermal channels which can 
be exploited for unauthorised application profiling. Sec¬ 
tion [7]and Section^ summarise countermeasures against 
thermal channels and related work respectively. Finally, 
we conclude in Section [3 


2 Background and Motivation 

In this section, we summarise the use of thermal infor¬ 
mation in modern processors and resource partitioning- 
based isolation techniques, as well as give a motivation 
for our study. 


2.1 Thermal Management 

Thermal management is key to the safe and reliable op¬ 
eration of modern computing systems. Today, thermal 
sensors are incorporated into a number of system com¬ 
ponents including hard-drives, DRAM, GPU, mother¬ 
boards and the processor chip itself 0. In this work, we 
focus on the information available from thermal sensors 
that are embedded in processor chips. 

Ensuring the thermal stability of a processor is be¬ 
coming increasingly challenging given the rising power- 
density in modern processor chips. As a result, ma¬ 
jor processor vendors (e.g., Intel, AMD, VIA) incorpo¬ 
rate thermal sensors to enable real-time monitoring of 
processor temperature. ARM-based processors also in¬ 
clude thermal sensors inside the system-on-chip (SoC) 
for power and temperature management. 


Initially, thermal management was done statically in 
hardware and included mechanisms to power-off the pro¬ 
cessor to prevent melt-downs. This later evolved to 
more sophisticated dynamic frequency and voltage scal¬ 
ing techniques that change processor frequency to lower 
its temperature |2Tj|24) . Hybrid software- and hardware- 
approaches to thermal monitoring have become popular 
over time; operating systems today poll temperature sen¬ 
sors and use this to manage cooling mechanisms such 
as processor frequency scaling and fan-speed [2|- More 
recently, there is a trend towards user-centric thermal 
management that exposes thermal data to users and al¬ 
lows them to implement customised thermal manage¬ 
ment policies. For example, Linux-based systems today 


enable users to configure thermal policies 112 171. 

The number and topology of thermal sensors depend 
on the processor vendor and family. For example, while 
Intel and VIA processors expose temperature data for in¬ 
dividual cores using on-die sensors, some AMD (e.g., 
Opteron K10 series) processors only allow monitoring 
the overall temperature of the entire chip using a sensor 
in the processor socket [[lj. Optimising the number and 
placement of thermal sensors on processors is an active 
research topic 136 42 44 46). 


2.2 Resource Partitioning-based Isolation 

Isolation techniques for multi-core platforms that are 
based on resource partitioning offer a number of bene¬ 
fits. First, resource management approaches that rely on 
partitioning reduce the size of the software Trusted Com¬ 
puting Base (TCB) {55) - In fact, some modern servers 
(e.g., from Hitachi) incorporate such hardware resource 
partitioning functions into firmware [ 6j and create mul¬ 
tiple, independent execution containers that can co-exist 
securely without the need for a software TCB. Second, 
the simplicity of partitioning-based resource manage¬ 
ment eases formal verification and this is leveraged by 
separation kernels like Muen JT8| . Third, modern pro¬ 
cessors rely on partitioning techniques to build Trusted 
Execution Environments (TEEs). TEE technologies such 


as Intel Trusted Execution Technology (TXT) 1321, Intel 
Software Guard Extensions (SGX) [41 ] and ARM Trust- 
Zone GD create isolated containers for the execution of 
sensitive software. Intel TXT relies on temporal parti¬ 
tioning of resources such as CPU and memory between 
trusted and untrusted software. Intel SGX and ARM 
TrustZone use temporal partitioning only for the CPU 
and implement spatial partitioning for memory resources 
in the system. 

Resource partitioning has already been proposed as a 
countermeasure against side-channels |25J. This is based 
on the understanding that processes can modify shared 
resources (e.g., cache, file) to communicate covertly or 
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exfiltrate sensitive information from victim processes by 
tracking the state of a shared resource such as cache. 
Therefore, there have been proposals for minimising 
shared resources to reduce the number and effective¬ 
ness of side channels. Examples include partitioning of 
caches (57) and and bus-bandwidth [26]. 

2.3 Motivation 

The main motivation behind this work is our observa¬ 
tion that despite its security advantages, resource parti¬ 
tioning on multi-core systems might not be able to com¬ 
pletely eliminate some types of inference or communi¬ 
cation across partitions. More specifically, we want to 
investigate if the exposure of core temperature informa¬ 
tion could be used to build both side channels and covert 
communication channels between processes that execute 
on different cores within a multi-core system. Our goal 
is to study these channels primarily in terms of their fea¬ 
sibility and throughput. 

Such channels are particularly interesting in the con¬ 
text of multi-core systems for two main reasons: (i) to¬ 
day, these platforms expose the information from ther¬ 
mal sensors to users and (ii) they can be tested for their 
effectiveness under the resource partitioning-based iso¬ 
lation mechanisms that multi-core systems can support. 
To build thermal side channels, it is necessary to under¬ 
stand the type and quality of temperature data available 
on systems today. One must also account for the nature 
of temperature variations on such systems and the factors 
that affect them. We focus on Intel x86 platforms for our 
study given their wide spread use. 

3 Thermal Behaviour of x86 Platforms 

In this section, we first describe the on-die thermal 
sensors available on Intel processors and then discuss 
the thermal behaviour of these platforms under a CPU¬ 
intensive load. 

3.1 Temperature Sensors in Intel 
Processors 

Intel labels each of its processors with a maximum junc¬ 
tion temperature which is the highest temperature that 
is safe for the processor’s operation. If the processor’s 
temperature exceeds this level, permanent silicon dam¬ 
age may occur. To avoid such processor melt-down, Intel 
facilitates processor temperature monitoring by incorpo¬ 
rating one digital thermal sensor (DTS) into each of the 
cores in a processor. The layout of the cores within a 
processor chip can be identified using lstopo (7). For 
example, on the Xeon server used in our experiments. 



Figure 1 : Thermal response of a CPU intensive appli¬ 
cation: Temperature trace resulting from the execution 
of an application that does RSA decryption in a loop for 
100 s. The start and end times of the application’s exe¬ 
cution are indicated using the two red lines. Temperature 
increases rapidly initially and saturates over time as an 
application runs. Similarly, it falls rapidly as soon as the 
core becomes idle and gradually returns to the ambient 
temperature. 

the cores are arranged along a line (as shown in Fig¬ 
ure |5). Each DTS reports the difference between the 
core’s current temperature and the maximum junction 
temperature 0. The accuracy of the DTS varies across 
different generations of Intel processors. They typically 
have a resolution of ±1°C. 

The absolute value of a core’s temperature in °C is 
computed in software by subtracting the thermal sensor 
reading from the maximum junction temperature. Ther¬ 
mal data from a sensor can be obtained using special 
CPU registers of the corresponding core. The data from 
all sensors is exposed using the coretemp kernel mod¬ 
ule |.Q on Linux systems and is accessible from user 
space through the sysfs filesystem which is refreshed 
every 2 ms. 

3.2 Example Temperature Trace 

To illustrate how computations affect the temperature of 
a core, we ran a CPU intensive application - more specif¬ 
ically, one that does an RSA decryption continuously in 
a loop. We ran the application on core 3 of an octa-core 
processor (for setup details, refer to Section |5T}. Fig- 
ure[T]shows the recorded temperature trace of core 3 dur¬ 
ing the execution of the application for 100 s (between 
the dotted red lines) on it and for about 50 s thereafter 
when the core cools. We observe that 25 ms after the ap¬ 
plication begins execution, the temperature rises by 5°C 
from approximately 35 °C to 40 °C. Following this rapid 
rise, the temperature increases very slowly and saturates 
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Figure 2: Heat Propagation from a Neighbouring Core: Effect of running a CPU-intensive application on core 3 of 
an octa-core processor for 100 s on the temperature sensors of its adjacent cores. 



Figure 3: Effect of processor frequency on thermal 
behaviour: Temperature profiles produced by running 
a CPU intensive application on a core at different pro¬ 
cessor frequencies for 100 s. 


at 43°C. As soon as the application stops executing, the 
temperature falls rapidly to 38 °C in about 25 ms and 
takes an additional 11 s to reach 35 °C. 

The exponential nature of the temperature rise and fall 
is a result of the system’s thermal capacitance and resis¬ 
tance. In fact, the temperature fall curve’s characteristic 


allows the temperature changes caused by such an appli¬ 
cation’s execution to be observed for sometime (in our 
example case, up to 11 s) after it has stopped. 

3.3 Factors Influencing a Core’s 
Temperature 

The major factors affecting the temperature at a particu¬ 
lar core are the fan speed, processor frequency and heat 
propagation from neighbouring cores. Since, in our ex¬ 
periments, we do not control the server fan speed (see 
Section |5T}, we only discuss the effect of the processor 
frequency and heat propagation on a specific core’s tem¬ 
perature below. 

CPU Frequency. Most Intel processors are designed to 
run at a set of discrete frequencies for optimising power 
consumption. For example, in our setup (Figure [5}, the 
Xeon server can run at frequencies between 1.2 GHz and 
2.9 GHz. All cores within a single processor chip run 
at the same frequency. Changes in frequency at a given 
core are reflected across all the other cores. The actual 
frequency can be controlled either by the user or by the 
kernel; for example, Ubuntu systems allow users to con¬ 
trol this using the sysctl interface HD- 
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HEAT-BASED CHANNEL IN SPATIALLY PARTITIONED SYSTEMS 
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On core C, the source executes a heat¬ 
intensive task (ON) to send bit '1' or 
remains idle (OFF) to send bit '0' 


On core C n _i, the sink continously 
records the temperature of the core on 
which it is executing 


The sink uses its recorded temperature 
trace to decode the information sent 
by the source 


HEAT-BASED CHANNEL IN TEMPORALLY PARTITIONED SYSTEMS 

INTERLEAVED EXECUTION ON THE SAME CORE 




On core C, the source executes a heat¬ 
intensive task (ON) to send bit 'I' or 
remains idle (OFF) to send bit '0' during 
its time-slice. 

The sink continuously records the 
temperature of its core during its time-slice 

The sink uses its recorded temperature 
trace to decode the information sent 
by the source 


Figure 4: Covert communication using thermal channels: We demonstrate that the temperature sensors on com¬ 
modity multi-core platforms can be misused for covert communication by two colluding processes in spatially and 
temporally isolated systems. 


Figure [3] shows how the processor frequency affects 
temperature when a CPU-intensive application runs for 
100 s. We can observe that higher frequencies result in 
more heat and higher saturation temperatures. This is 
because processor operation at a higher frequency results 
in a larger power density and therefore, more heat. 

Heat Propagation From a Neighbour. The heat re¬ 
sulting from computations on one core will propagate to 
neighbouring cores. As a result, the temperature at a cer¬ 
tain core depends not only on that core’s workload (type 
of computation and schedule) but also those of its neigh¬ 
bours. 

Figure [2] shows the effects of a CPU-intensive applica¬ 
tion executing on a central core (core 3) of an octa-core 
processor for 100 s. We notice that the computation on 
core 3 affects the temperature sensors of its neighbouring 
cores which remain idle all through. Additionally, we 
observe that the saturation temperature of a neighbour¬ 
ing core decreases with increasing distance from core 3. 
This effect is not symmetric as one would expect on ei¬ 
ther side of core 3. We suspect that this is due to an 
asymmetrically located processor hotspot. 

4 Exploiting Thermal Behaviour 

In this section, we present the intuition underlying the 
construction of thermal side channels on multi-core sys¬ 
tems which implement spatial or temporal resource par¬ 
titioning for isolation. 


4.1 Isolation based on Spatial and 
Temporal Partitioning 

Isolation techniques that rely on resource partitioning are 
becoming increasingly popular and there have been a 
number of proposals for using such partitioning to pre¬ 
vent covert channels (26j[57j. We consider two most 
common types of process isolation and partitioning tech¬ 
niques in our work: spatial and temporal (Figure [4}. 
In spatially partitioned systems, processes are isolated 
by being assigned exclusive computation resources, i.e., 
no two processes share cores or memory. Such an ap¬ 
proach prevents certain types of side-channels between 
processes that execute concurrently. For example, cache¬ 
partitioning prevents any information leakage that may 
occur based on state of the cache-lines in a processor 
(e.g., how many cache-lines are full). In such systems, 
processes do not share any processor temperature sensors 
because they do not use any common CPU resources. 

In temporally partitioned systems, the processes share 
the same resources but run in a time-multiplexed man¬ 
ner. For example, this technique is used by TEEs like 
Intel TXT in which only one of two partitions (trusted 
or untrusted) are active at a time but have access to com¬ 
mon cores and memory. In systems that employ temporal 
partitioning, processes that share one or more cores have 
access to the corresponding temperature sensor(s) during 
their execution time-slice. 

Thermal side channels that leverage system thermal 
behaviour can be used to circumvent both these types of 
isolation techniques as we describe below. 
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4.2 Constructing Thermal Channels 

Based on our discussion in Section [3] we make two 
observations that can be used to construct thermal side 
channels. 

1. Remnant Heat. Since temperature variations that 
result from a computation can be observed even af¬ 
ter it stops, these variations leak information regard¬ 
ing the computation to the process that follows it 
in the execution schedule especially if it is on the 
same core. This remnant heat can be exploited as 
a thermal side channel and may allow a process to 
exfiltrate sensitive information from its predeces¬ 
sor thereby violating temporal partitioning. Fur¬ 
thermore, it can also be used for communication 
between two colluding processes that time-share a 
core. Note that while it is possible to reset most 
resources (e.g., CPU registers, caches) to prevent 
other side channels before switching between appli¬ 
cations, the remnant heat from a computation (and 
hence, a thermal side-channel) is hard to eliminate. 



Figure 5: Our Experimental Setup: Our framework 
consists of an Intel Xeon-based server platform running 
Suse Linux. We use cpusets to achieve spatially or tem¬ 
porally isolated source and sink applications. We wrote 
a custom source application that uses RSA decryption 
operations to generate heat and a sink application that 
records its own core’s temperature continuously. 


2. Heat Propagation to a Neighbouring Core. The 

thermal conductivity of the processor results in heat 
propagation between cores, i.e, the heat that results 
from a computation not only affects its underlying 
core’s temperature but also its neighbouring cores. 
As a result, this heat flow can be exploited as a ther¬ 
mal channel by an attacker to either make inferences 
about a potentially sensitive computation at a neigh¬ 
bouring core or by colluding processes to communi¬ 
cate covertly thereby violating spatial resource par¬ 
titioning. Since it is hard to eliminate heat flows 
within processors, thermal side channels remain a 
viable threat even in spatially partitioned systems. 

There are several challenges involved in the construc¬ 
tion of thermal side channels. First, the nature of temper¬ 
ature changes makes it hard to control the effect that an 
application’s execution will have on the temperature of 
its own core and its neighbours. Second, the limited res¬ 
olution of the temperature sensors available on current 
x86 platforms prevents fine-grained temperature moni¬ 
toring. Finally, fan-based cooling mechanisms affect the 
rate and extent of temperature variations. 

5 Covert Communication Using Thermal 
Channels 

In this section, we present the feasibility and through¬ 
put of communication using thermal covert channels in 
spatially and temporally partitioned multi-core systems. 
We begin by describing our experimental setup that im¬ 
plements such isolation mechanisms below. Throughout, 


we refer to the data sender as the source and the recipient 
as the sink. 

5.1 Experimental Setup 

Our setup is based on an Intel server containing two octa- 
core Xeon processor chips and running an Open SUSE 
installation (Figure |5J. We use cpusets Q to implement 
spatial and temporal partitioning. Using this, we restrict 
the OS to one of the processor chips (Processor 2) and 
isolate it from the rest of the system. We achieve spatial 
partitioning by running the source and the sink on sepa¬ 
rate cores on the Processor 1 with minimal interference 
from the OS. To realise temporal partitioning, our sys¬ 
tem incorporates a scheduler that controls the duration 
and cores on which the source and sink execute. 

We wrote a custom application that performs an RSA 
decryption (using PolarSSL fTO) ) continuously in a loop 
and use it as the source application of the covert channel. 
Similar to popular thermal benchmarks (e.g., CStress pj, 
mprime |[8j), this application extensively uses the CPU 
register file and ALU and can therefore, increase the tem¬ 
perature of its underlying core quickly. 

We rely on the server fan for cooling the cores. Our 
server allows the fan-speed to be configured only through 
the BIOS and we set this to a maximum speed of 15000 
rpm for our entire study. We chose this setting because 
it is the most likely setting for servers which run com¬ 
putationally intensive tasks. Our server is currently in 
a room whose ambient temperature is around 22°C. We 
also implemented a custom sink application that records 
the temperature of the core on which it executes contin- 
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uously. 

Our experimental framework is implemented using 
C and allows configuration of run-time parameters like 
the processor frequency, set of applications to run, their 
schedule and mapping to cores. Initialisation and tear 
down of the measurement framework is performed using 
a set of Perl and Bash scripts. Our setup allows us to 
achieve strong spatial and temporal isolation; this makes 
it an ideal platform for our investigation of thermal side 
channels. 

5.2 Covert Communication in Spatially 
Partitioned Systems 

This section addresses the construction of thermal chan¬ 
nels in the scenario where the source and sink applica¬ 
tions run on dedicated cores and execute concurrently. 
The sink has access only to its own core’s temperature 
sensor and not that of the source as described in the up¬ 
per part of Figure [4] To communicate covertly in such 
a scenario, the source exploits the heat propagation from 
its own core to the sink that runs on a neighbouring core. 
In this section, we demonstrate the feasibility of achiev¬ 
ing this on a commodity multi-core platform and evaluate 
the throughput of such a communication channel. Below, 
we first present the encoding scheme that we use for data 
transmission and then describe the experiments that re¬ 
alise covert communication using the thermal channel. 

Encoding and Decoding. The source and sink use the 
ON-OFF Keying for their communication. To send bit 
T’, the source application runs RSA decryption opera¬ 
tions to generate heat and to transmit bit ‘O’, it remains 
idle. It is important that the source application runs long 
enough to affect the sink’s temperature sensor on a neigh¬ 
bouring core to send bit ‘1’, i.e., it must generate enough 
heat to raise the temperature of the sink’s core above the 
ambient temperature. We denote the the minimum dura¬ 
tion for which the source application needs to execute to 
transmit a ‘1’ bit to the neighbouring cores as T/,. The 
source remains idle for the same duration to send a ‘0’ 
bit. We assume that the source and sink agree on T* and 
a fixed preamble to mark the start of the data apriori. 

The sink that records the temperature of its own core 
continuously does the following to decode the data. It 
first searches the recorded temperature trace for a fixed 
preamble. We choose a preamble starting with bit T’ 
because it can clearly be identified by the sink. To de¬ 
tect the start of the preamble, the sink searches for a ‘ 1 ’ 
bit by detecting the first rising edge, i.e., a temperature 
increment >2°C given its ambient temperature. We use 
this threshold because the resolution of the sensors on the 
platform is ±1°C. It then tries to decode the bits follow¬ 
ing this to see if they match the preamble. The source 
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Figure 6: Temperature drift due to the sink’s execu¬ 
tion: The temperature drift caused by the execution of 
the sink itself is very slow as shown here. This trace was 
recorded over 400 s by running the sink application on 
core 3 with all the other cores idle. Note that the resolu¬ 
tion of the sensor is ±1°C. 

repeats this until it recovers the preamble from the tem¬ 
perature trace. It then decodes the remaining bits using a 
simple edge detection mechanism in which a rising edge 
indicates bit ‘1’, a falling edge indicates bit ‘0’ or a no¬ 
change implies that the value is the same as the previous 
bit. 

Temperature Drift due to the Sink’s Execution. The 

sink relies on the source to affect its core’s temperature 
sensor for communication. However, to do this, it is 
necessary to isolate any temperature drifts that may be 
caused by the sink’s execution itself on its own tempera¬ 
ture sensor. 

To understand these drifts better, we run the sink for 
a long time and observe its temperature. Figure [6] shows 
the temperature trace of core 3 when the sink is running 
on it for 400 s while the other cores are idle. The core’s 
temperature remains stable at around 33°C for 200 s and 
later drifts slowly towards 34°C. Therefore, we conclude 
that the temperature changes caused by the execution of 
the sink process itself is negligible over a long duration 
of time (e.g., 200 s). 

Calibration of T*,. Before the actual transmission of 
data, we have to determine the optimal value of T^, i.e., 
the duration for which the source executes or remains 
idle to send bit ‘1’ and bit ‘0’ respectively. Note that 
the actual value of T* depends on the relative locations 
of the source and the sink. This is because the effect 
of the source’s execution affects the cores farther away 
from it to a lesser extent (see Section [3]). For our first 
experiments, we fix the source to execute on a core 3 
because it is a central core and the sink to execute on 
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Figure 7: Thermal communication in spatially iso¬ 
lated systems: Temperature traces recorded during the 
transmission of the 30 bits (15 ones and 15 zeroes) from 
the source (core 3) to the sink (core 2) using a of 
750 ms. 
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core 2. We later describe the effects of increasing the 
distance between the source and the sink on T^. 

To estimate T*, we first set it to a value between 50 ms 
and 1500 ms. We then attempt to send 100 data bits from 
the source on core 3 to the sink on core 2 and observe 
the resulting temperature traces on core 2. We do this by 
configuring the source application to be active and stay 
idle for T^ alternately. Our data bits consists of 50 al¬ 
ternating ones and zeros. We choose this data sequence 
because it is important to ensure that the chosen T/ ; con¬ 
sistently results in the desired temperature increment on 
core 2. 

We were unable to decode data when T/ ; was smaller 
than 250 ms. We observe that data transmission using 
T b> 500 ms results in about 10% bit errors (Table [TJ. 
Furthermore, we notice that the bit error rate does not im¬ 
prove much by increasing T* from 500 ms to 1500 ms. 
Figure [7] shows the temperature traces of the two cores 
during the data exchange using a T/,=750 ms. The data 
shown here has been post-processed to remove noise us¬ 
ing a smoothing function. We observe that the tempera¬ 
tures of core 3 and core 2 are well-correlated (correlation 
co-efficent ~ 0.6 %, p-value = 0). 

Error Rate. To understand the nature of errors in ther¬ 
mal channels, we send a pseudorandom sequence of a 
1000 bits in 100-bit blocks. Each block begins with a 
preamble to enable the sink to detect the start of data 
transmission. 

From our initial experiments, we observe that the tem¬ 
perature traces of core 2 and core 3 are well-correlated in 
time over a sequence of alternating ones and zeros (Fig¬ 
ure |7}. Therefore, we choose a preamble of five alter¬ 
nating ones and zeroes (10 bits in total). The source and 


Tfc(ms) 

Bit Error (%) 

Core 2 
(1-hop) 

Core 1 
(2-hop) 

250 

18 

- 

500 

14 

- 

750 

13 

- 

1000 

11 

24 

1250 

9 

26 

1500 

8 

15 


Table 1: Calibration of T* in spatially partitioned sys¬ 
tems: We send a block of 100 bits consisting of alter¬ 
nating ones and zeroes using different values from 
the source (core 3) to the sink that runs at one and two 
hop distances from it. The processor frequency was set 
to 2.9 GHz and this table shows the resulting bit-error 
rates (‘-’ indicates that the data could not be decoded). 
We observe when T/,> 500 ms, we can decode data with 
less than 15% error at one hop but this does not improve 
much by increasing T/, to 1500 ms. We also notice that 
the required T^ increases with greater distance from the 
source. At a one hop distance, setting T/,=750ms and 
using Hamming(7,4) error correction code results in a 
channel throughput of up to 0.33bps. 


sink synchronise in 9 out of 10 tests and the average er¬ 
ror rate is 13.22 % (± 5.19) for a T*, value of 500 ms. 
On increasing T^ to 750 ms and 1000 ms, the source and 
sink synchronise over all 10 tests and the average error 
rate is 11.3% (± 2.83) and 11% (± 3.83) respectively. 


Varying the Sink’s Location. We repeat similar ex¬ 
periments by running the sink in core 1 and core 0 which 
are two and three hops away from the core 3 to see how 
the error rate varies with increasing distance from the 
source. At a two hop distance, we observe that for a 
given T/ ; , the error rate is higher than in the case of the 
one hop (Table |T]». At a three hop distance, we were un¬ 
able to decode data at 1500 ms. However, increasing the 
value of T/, sufficiently will allow data transmission at a 
3-hop distance. For example. Figure 2(c) shows an ex¬ 
treme case in which T/, is set to 200 s to transmit bit ‘1’. 


The increased error rate and deterioration in the abil¬ 
ity to decode data is expected because heat resulting from 
computations at a given core affects the cores closer to it 
more than the cores farther away. We repeated the exper¬ 
iments to estimate the error rate from the source (core 3) 
to a sink running on core 1 at a two hop distance. We 
observe that the source and sink synchronise success¬ 
fully in 9 out of 10 tests. We can transmit data at the 
rate of 1 bit in 1.5 s (T* = 1500 s) with an error rate of 
18.33% (±4.21). 
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Effect of Frequency on T/,. To understand the effect of 
processor frequency on T/„ we repeated our experiments 
for 1-hop communication at a lower frequencies, namely, 
2.4 GHz and 1.9 GHz. As shown in Table [2] for a given 
T/,, the error rate increases at lower processor frequen¬ 
cies. When the processor frequency is set to 1.9 GHz, 
we could not decode data even at 1500 ms. We note that 
using a larger value for T*, would solve this problem and 
can be done using the same methodology we used for 
our experiments. This deterioration in error rates and the 
ability to decode data itself is expected because lower 
frequencies result in lesser heat generation from a given 
computation and therefore, the rise in temperature may 
not be significant enough to detect a bit ‘I’ . 

We repeated the data transmission experiments when 
the processor frequency is set to 2.4 GHz. We transmit a 
pseudo-random sequence of 1000 bits in 100-bit blocks, 
each prepended with a preamble, from the source (core 3) 
to the sink (core 2) using T/,= l 250 ms and 1500 ms. 
In both cases, the source and sink sychronise in all 10 
tests. The observed error rates in both cases is similar, 
i.e., 14.9% (± 3.9) and 15.9% (± 6.08) for T i= 1250 ms 
and T/,= 1500 ms respectively. 

Throughput Estimation. From the above discussion, 
we conclude that the throughput of thermal covert chan¬ 
nels in spatially partitioned systems depends on number 
of factors including the time required to transmit one bit 
of information (T^) and error rates; both these parame¬ 
ters in turn depend on the processor frequency and the 
distance between the colluding processes. 

At 1-hop distances, given a T/, of 750 ms, the through¬ 
put would be 1.33 bps in the ideal case without any er¬ 
rors. However, due to the 11% errors that we observe 
in the experiments, actual communication would require 
error correction to be implemented. When we analysed 
the nature the errors, we found that for every four bits, 
with a probability of over 0.9, there was one or no er¬ 
rors. Therefore, we could use a Hamming (7,4) error- 
correction code to correct for these errors and this would 
result in 75% overhead and hence, an effective through¬ 
put of 0.33 bps. When the frequency is changed to 
2.4 GHz, the throughput is about 0.2 bps using a Ham¬ 
ming (7,4) error correction code. A similar trend was 
observed on increasing the distance between the source 
and sink. 

Finally, we note that the actual throughput of such 
a thermal communication channel in particular systems 
will depend on the actual machine and its workloads. 
Our experiments were performed in conditions that min¬ 
imise any noise from the OS, other processor workloads 
(e.g., only the source and the sink are active), etc. and 
the above estimates are representative upper bounds on 
the throughput of thermal channels on such a platform 


Tft(ms) 

Bit Error (%) 

2.9 GHz 

2.4 GHz 

250 

18 

- 

500 

14 

23 

750 

13 

24 

1000 

11 

23 

1250 

9 

14 

1500 

8 

14 


Table 2: Effect of processor frequency on required 

T^: We send a block of 100 bits consisting of alternat¬ 
ing ones and zeroes using different T/, values from the 
source (core 3) to the sink (core 2). The table shows the 
resulting bit-error rates at different processor frequencies 
(‘-’ indicates that the data could not be decoded). We ob¬ 
serve that when the processor runs at lower frequencies, 
T/ ; has to be increased to achieve lower bit-error rates. 

with spatial partitioning. Any additional processes that 
run alongside the source and the sink are likely to cause 
more communication errors depending on their relative 
location with respect to the source and the sink because 
they would contribute to the temperature variations at the 
sink’s core and hence, lower the throughput. 

5.3 Covert Communication in Temporally 
Partitioned Systems 

Temporal partitioning schemes securely multiplex the 
same resources (e.g., cores, memory) between several 
applications. Systems that use this technique mitigate 
information leakage through side channels by clear¬ 
ing caches, registers, etc. while switching between pro¬ 
cesses. However, the thermal footprint of an application 
(the source in our case) remains intact for observation by 
the other application that executes after it on the same 
core (the sink in our case). This is a result of the ther¬ 
mal capacitance and resistance of processors and can be 
exploited to communicate covertly. We demonstrate this 
through our experiments below. 

Scheduling, Encoding and Decoding Schemes. In 

temporally partitioned systems, a scheduler determines 
the order in which different partitions execute on a core 
and therefore, we implement a scheduler (Figure [5]) that 
realises this functionality. Since the sink and source 
share the same core, they run in an interleaved manner 
and the sink has access to the temperature sensors only 
during its execution time-slice (t s ). Temperature varia¬ 
tions over the course of the source’s execution within one 
time-slice are not visible to the sink; instead the sink only 
has access to the final temperature after the source’s exe¬ 
cution time-slice. Therefore, in our implementation, the 
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Time (s) 

Figure 8: Thermal communication in temporally iso¬ 
lated systems: Temperature traces recorded during the 
transmission of the 6 bits ( 3 ones and 3 zeroes) from the 
source to the sink. The source and the sink execute in 
alternate time-slots of 10 ms (marked in grey) on core 3. 
The thick lines are the actual temperature traces recorded 
by the sink and the dotted lines represent the temperature 
changes that occur as a result of the source’s execution. 


source sends a single bit per time-slice (using the tem¬ 
perature at the end of that time-slice) to the sink over a 
thermal covert channel. In other words, the bit length is 
equal to the the execution time-slice, t s . We use the same 


ON-OFF keying technique as before in Section 5.2 


Calibration of T/,. We consider the scenario in which 
the sink and the source share a core and run in a round- 
robin fashion. The source heats up the processor (bit ‘1’) 
or stays idle (bit ‘0’) to send one bit of information to the 
sink application that runs immediately after. 

In order to understand how fast one can transmit bits 
over such a channel, we do the following. We vary T/, 
between 10 ms (which is the minimum value that our 
framework allows) and 30 ms and try to send an alternat¬ 
ing sequence of 50 ones and 50 zeroes from the source to 
the sink. The source and sink run on core 3 in our experi¬ 
ments. Figure[8]shows an example temperature trace that 
the sink records during its execution. Note that the sink 
has access to the shared core’s temperature sensor only 
during its own time-slice. We observed no errors in the 
data that the sink decodes even for T/, > 10 ms and there¬ 
fore, use this value for further experiments. We also re¬ 
peated the experiment on the cores at the corners (core 0 
and core 7) and noticed similar results. 


Error Rate. To understand the nature of errors in this 
channel, we send a pseudorandom stream of 1000 bits 
in 100-bit blocks using T/,= 10 ms. We send 10 bits for 
synchronisation at the beginning of every block similar 


Tfc(ms) 

Bit Error (%) 

2.9 GHz 

2.4 GHz 

1.9 GHz 

10 

0 

4 

0 

15 

0 

1 

1 

20 

0 

0 

1 

25 

0 

0 

0 

30 

0 

0 

0 


Table 3: Effect of processor frequency on required 

T/,: We send a block of 100 bits consisting of alternat¬ 
ing ones and zeroes using different T/, values from the 
source (core 3) to the sink that runs on the same core. 
The table shows the resulting bit-error rates at different 
processor frequencies. We observe that the error rates do 
not change much even at lower processor frequencies. 
Setting the frequency to 2.4 GHz, T b to 10 ms and using 
Hamming(7,4) error correction code leads to the channel 
throughput of up to 12.5bps. 


to the experiments in Section [572] The synchronisation 
using the preamble was successful in all cases and the 
data transmission resulted in error rates of 7.6% (± 1.9), 
9.5% (± 4.86) and 7.1% (± 2.23) for experiments on 
cores 0, core 3 and and core 7 respectively. 


Effect of processor frequency on T/ ; . We repeated our 
experiments at two lower processor frequencies (2.4 GHz 
and 1.9GHz) to understand how it may affect the required 
T b for reliable communication. In the T/, calibration ex¬ 
periments, the error rates remain low despite the decrease 
in frequency (Table [3j. In the actual data transmission 
tests (of 1000 bits in 100 bit blocks) at 2.4 GHz, the 
source and the sink successfully synchronise in all 10 
tests and the error rate is about 6.5% (±3.58). At 1.9 
GHz however, the synchronisation succeeds only 5 out 
of 10 times and the error rate is 9.5% (±2.55). This indi¬ 
cates that a higher T/, value is required for more reliable 
communication at a processor frequency of 1.9 GHz. 


Throughput Estimation. The throughput of the ther¬ 
mal channel in temporally partitioned systems depends 
on the execution time-slice per application, their sched¬ 
ule and the time required to send one bit of informa¬ 
tion (T/,). If the execution time-slice (t j < T/ ; , then com¬ 
munication becomes difficult because the source cannot 
generate enough heat to transmit ‘1’ bits. However, if 
tv > T b , then the source can choose to execute for long 
enough to cause a temperature change that the sink no¬ 
tices. We note the typical Linux systems have a time- 
slice of about 100 ms which is 10 times bigger than the 
one we need for implementing thermal covert channels. 

When T b (also, equal to t v ) is 10 ms, we would expect 
the throughput of the thermal channel would be 50 bps. 
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However, since the communication is error prone and re¬ 
sults in up to 10% error, the encoding scheme would have 
to incorporate error correction codes. On analysing the 
nature of the errors during the transmission of a 1000 
bits, we see that with a probability of over 0.9, there is 
1 or no errors in every four data bits. Therefore, we can 
use a Hamming(7,4) code to overcome these errors and 
this results in an effective throughput is about 12.5 bps. 
This throughput is independent of which particular core 
the source and sink share (core 0/3/7). A T/, of 10 ms 
results in low error rates even at a processor frequency of 
2.4 GHz and hence, the throughput is roughly 12.5 bps. 

We note that the actual throughput of thermal channel 
in a particular system would depend on its hardware and 
its workloads. In our experiments, we minimise noise 
from running the source and sink in isolation from the 
rest of the system (OS, other workloads, etc.) and there¬ 
fore, the results we present are representative of upper 
bounds on the achievable throughput on our platform im¬ 
plementing temporal partitioning. This is because any 
additional workloads that run along with the sink and 
source processes would affect the temperature traces that 
the sink records and hence, lower the throughput. 

6 Thermal Channels for Unauthorised 
Profiling 

In this section, we present a preliminary study of how 
thermal side channels enable unauthorised thermal pro¬ 
filing of processes even in systems that implement strong 
isolation mechanisms like spatial resource partitioning. 

Since the heat generated from an application ( victim ) 
can be observed from its neighbours, this may leak in¬ 
formation regarding the nature of its computation to pro¬ 
cesses at other cores. More specifically, if the attacker 
has reference thermal traces for victim applications, he 
can recognise if and when such an application executes 
on a neighbouring partition. For example, identifying 
that a sensitive or potentially vulnerable application is 
running on a neighbouring core may aid an attacker in 
preparing or launching an attack. Application identifica¬ 
tion based on temperature traces has not been addressed 
previously in literature and below we present a first study 
that tries to understand its effectiveness as an attack vec¬ 
tor. 

Goal and Intuition of the Attack. We assume that an 
attacker has access to a reference thermal trace of the vic¬ 
tim application (say RSA decryption); such a trace can 
be obtained by the attacker if he has access to a similar 
platform as the one he is attacking. The attacker’s goal 
is to verify if the temperature trace of his core is a result 
of the victim application’s execution on a neighbouring 



Figure 9: Example Temperature traces of different 
applications: We ran a set of five CPU intensive appli¬ 
cations (RSA decryption, BitCount, QSort, BasicMath, 
ADPCM) from a popular MiBench benchmark suite [1271 
for 200 s one each at a time and recorded the resulting 
temperature traces on a neighbouring core. 

core. Note that the attacker does not have access to the 
temperature trace of its neighbouring core(s) but only to 
that of his own core. For simplicity, we assume that only 
the attacker and the victim are active during the attack 
and that they are collocated on adjacent cores. The at¬ 
tacker continuously monitors his own core’s temperature 
and then, correlates it with a reference trace of the vic¬ 
tim application. A strong correlation indicates that the 
attacker’s temperature trace was a result of the execution 
of the victim application with high probability. 

Experiments and Analysis. We chose a set of five 
CPU-intensive applications including RSA decryp¬ 
tion and four applications from a benchmark suite, 
MiBench [27j (ADPCM, Quick Sort, BitCount, Basic- 
Math) and use them as the universal set of applications 
that a victim core (core 3) executes. We intentionally 
chose similar applications all of which stress the ALU 
and register file region of the core because this is harder 
than distinguishing between applications that are very 
distinct, for example, ones which stress the caches as op¬ 
posed to the register file. 

To understand the feasibility of identifying these ap¬ 
plications, we ran each of them for 200 ms on core 3 
of our setup (Section [5.1) and collected the temperature 
traces of a neighbouring core (core 2). We repeated this 
five times for each of the applications and Figure[9]shows 
one such trace for each of them. We observe that the sat¬ 
uration temperature for each of the traces is different. 

We use a simple correlation as a metric to measure 
similarity/differences between pairs of applications. On 
correlating the traces from the RSA application, we ob¬ 
serve that the correlation is higher than 85% in seven out 
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of ten (since there are 5 runs, we have 10 pairs to cor¬ 
relate) occasions. Using this same correlation threshold 
of 85% also results in 28% false positives when the RSA 
application is correlated with the others from the bench¬ 
mark suite. In general, traces belonging to the same ap¬ 
plication have high correlation values (>80%). How¬ 
ever, traces belonging to different applications also show 
high correlation because they are all CPU intensive and 
stress similar parts of the CPU (>75%). Therefore, we 
conclude that using a simple correlation metric would 
only allow distinguishing applications that behave very 
differently and more sensitive metrics (such as thermal 
models |48j or machine-learning based classifiers) are 
required for better accuracy in other cases. 

Finally, more fine-grained data exfiltration (e.g., de¬ 
ducing AES or RSA keys) on commodity x86-systems 
using the thermal side-channel is an open, unexplored 
problem. A key challenge is the limited resolution of the 
temperature sensors which is ±1°C and the rate at which 
the sensors are refreshed (currently, once every 2 ms). 


7 Discussion 

In this section, we present possible countermeasures 
against thermal covert-channels and discuss their limi¬ 
tations. We also discuss a security-application that can 
leverage thermal side channels. 


state. Since all these parameters are usually common 
across cores or subsets of cores within a processor chip, 
they can still provide a signalling mechanism. Finally, 
while it may be possible to separate processes in time 
and spatially to limit the effectiveness of thermal chan¬ 
nels, such resource allocation strategies are wasteful and 
result in low resource utilisation. 


Thermal Fingerprinting For Security. Although so 
far we discussed only how thermal behaviour of systems 
can be exploited by attackers, the same properties could 
be used for achieving better security. Since tempera¬ 
ture changes resulting from computations are difficult to 
avoid, we hypothesise that thermal profiling techniques 
can also be used to detect any anomalous behaviour in 
the execution of an application. More specifically, it is 
highly likely that run-time compromise of an application 
results in a temperature trace that does not match its orig¬ 
inal thermal fingerprint. It has been shown to be possible 
to extract thermal models by monitoring the application 
under controlled conditions 148 49). By comparing the 
actual execution trace to the expected trace, it may be 
possible to detect run-time compromise of software ap¬ 
plications but this needs further exploration. 


8 Related Work 


Countermeasures. Since we leveraged the tempera¬ 
ture information exposed to software to construct thermal 
side channels, a natural solution to this problem would be 
to restrict access to temperature sensors on the system. 
However, such information cannot always remain hid¬ 
den. For example, in cloud systems, it is important for 
a guest operating system to track temperature informa¬ 
tion not only to schedule intelligently but also to under¬ 
stand if any of its user processes are misbehaving. Fur¬ 
thermore, centralised control and monitoring of thermal 
states does not scale well with the advent of many-core 
processors 131 56) that contain hundreds of cores and 
host a large number of autonomous processes on sepa¬ 
rate cores. In fact, research prototypes like Intel’s SCC 
platform (33) already allow subsets of cores to adminis¬ 
ter their frequency and voltage independently for power- 
efficiency; temperature information is a vital input to this 
decision process. Therefore, there is a clear tension be¬ 
tween securing platforms and improving their energy- 
efficiency by exposing thermal data to the software on 
them. 

Even if one restricts access to the temperature sensors, 
related information such as clock skew, fan speed and 
even frequency in systems that allow dynamic frequency 
scaling still leak information about the system’s thermal 


We review previous work on temperature-related chan¬ 
nels and other side-channels in general on x86-systems. 
We also provide some examples of existing literature on 
optimizing computing systems for thermal efficiency be¬ 
cause it highlights the advantages of exposing thermal 
data as opposed to the other work that misuses this data 
to undermine security. 


Thermal Channels and Attacks. There is no previ¬ 
ous work that demonstrates the feasibility of thermal 
side channels and their use for covert communication on 
commodity multi-core systems as we do in this paper. 
Previously, two works discussed and one implemented 
thermal covert channels on FPGA boards [ 15l |3Q||40) . 
There have also been attempts to transmit data between 
two processes by changing fan-speed & The abil¬ 
ity to remotely monitor a system’s clock-skew (influ¬ 
enced by the changes in the system temperature) has 
also been exploited in the past for exposing anonymous 
servers (45]|63) and covert communication with a re¬ 
mote entit y (62) . We note that although some of these 
works OH 113 use the term thermal channel, none of 
them use the thermal information available on modern 
systems to covertly communicate between processes on 
the same host as we do in this paper. 
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More recently, it has been shown that it is possible to 
use temperature variations to induce processor faults m 
which can in turn be also be used to extract sensitive in¬ 
formation like RSA keys |29) . Thermal information can 
also be used for coarse-grained data-exfiltration. For ex¬ 
ample, since temperature directly reflects the intensity 
of computation, it can be used to estimate the load or 
resource utilisation of a machine. This was illustrated 
by Liu et al. who computed the resource utilisation of 
servers in Amazon’s EC2 although in a completely dif¬ 
ferent context using the temperature data that is exposed 
to virtual machines (38). 


Temperature-based Denial-of-Service Attacks. Pre¬ 
vious research has identified other security risks that 
arise from hardware and software thermal management 
techniques on modern systems. For example, mali¬ 
cious processes may cause a denial-of-service by slowing 
down the processor [28 1 or permanently damaging hard¬ 
ware by causing thermal hotspots |23) . Such processes 
could also exploit the fact that certain architecture com¬ 
ponents (e.g. instruction cache) are ignored by thermal 
optimisation approaches on modern processors |34) . 


Covert channels on x86-systems. Originally defined 
by Lampson as part of the confinement problem [35], 
today, several side channels have been identified and 
explored in the context of x86 systems. One of the 
most studied side-channels on x86-systems is the cache- 
based channel which can be used for both covert data ex¬ 
change f60) and data exfiltration j64). Covert channels 
based on bus contention have also been shown to be fea¬ 
sible 1591. Network stacks ]43| , file-system objects |35| , 
input devices [52) and virtual memory ]54) have all been 
shown to support covert-channels. 

A typical way to prevent the above side channels is to 
partition them and is used for example to mitigate cache- 
based channels 157 ] and bus-based channels f26| (by re¬ 


serving bus bandwidth in this case). However, such parti¬ 
tioning techniques will not eliminate temperature-based 
channels completely as we have shown in this paper. 


Thermal Monitoring of Processors. Temperature 
management of computing systems has gained signifi¬ 
cance over the last few years given the trend of increas¬ 
ing on-chip temperatures of modern processors. This has 
resulted in efforts to design and implement better thermal 
management techniques for processors including opti¬ 
mization of sensor placement (e.g., |42||44l|46] ), improv¬ 
ing algorithms for dynamic temperature management 
(e.g., {STj) and cooling techniques f20) . There are also 
ongoing efforts to develop frameworks to thermally pro¬ 
file applications |49j |, temperature-aware schedulers G3 


[22| and micro-architectures (37[|53| . 

Thermal profiling can further be used to detect com¬ 
promised process in embedded systems [58] and design 
schedulers such that they do not leak information through 
thermal fingerprints of applications G3- 


9 Conclusion 

In this paper, we demonstrated the feasibility and poten¬ 
tial of thermal side channels on commodity multi-core 
systems. We showed that such channels can be built 
by exploiting the thermal behaviour of current platforms 
and can be used to circumvent strong isolation guaran¬ 
tees provided by temporal and spatial partitioning tech¬ 
niques. Our experiments indicate that it is possible to use 
them for covert communication between processes and 
achieve a throughput of up to 12.5 bps. We also demon¬ 
strated that thermal channels can be exploited to profile 
applications running on a neighbouring core. 

Attacks based on thermal channels are further facil¬ 
itated by the increasing trend towards exposing system 
temperature information to users, allowing them to make 
thermal management decisions for efficient operation. 
Our work therefore, not only points out a serious limita¬ 
tion in the isolation guarantees that resource partitioning 
techniques can provide but also highlights the tension be¬ 
tween designing systems to support user-centric thermal 
management for efficiency and security. 
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